Ian & Stuart's Australian Mac: Not for Sale/Another.not.for.sale (Australia).iso/fade into you/being there/How To & FAQ's/UNIX-Email-Software-SurveyAQ

Text File | 1994-11-13 | 62KB | 1,341 lines

        UNIX EMail Software - a Survey
               Chris Lewis
        [e-mail]
        [and a host of others - thanks]

Changes this issue: "mailagent" a new mail filter.  Sendmail 6.1

Note: this FAQ has been formatted as a digest.  Many newsreaders
can skip to each of the major subsections by pressing ^G.

Please direct comments or questions to [e-mail] -
note Reply-to: line.

--------
~Subject: Introduction

Configuring electronic mail systems can be quite a complicated
subject.  Often far more complicated than, say, setting up
a USENET news feed.  This is because, unlike news, email is
expected to traverse multiple types of networks using their own
protocol, whereas, USENET news tends to be a single protocol
supported by hook or by crook on different networks.

This document is intended for system administrators who need to
know how to set up their UNIX systems for email communication with
the outside world.  It is intended for the email-naive SA
who gets more than a little confused by the acronyms, RFC's and
plethora of software.

This is intended to be a general survey of the software available,
so I won't spend too much time on some of the details.  Most of
the available software comes with documentation that can
explain things much better than I can.

Additional detail can be obtained from several sources, such as:

    Quarterman, John S.: "The Matrix -- Computer Networks
    and Conferencing Systems Worldwide", Digital Press 1990,
    (Order No.  EY-C176E-DP), ISBN 1-55558-033-5.

    Adams, Rick and Frey, Donnalyn: !%@:: A Directory of Mail
    Addressing and Networks, 2nd Ed., O'Reilly & Associates 1990,
    ISBN 0-937175-15-3.

    Kehoe, Brendan P.: Zen and the Art of the Internet: A
    Beginner's Guide, Second Edition, Prentice Hall 1992,
    ISBN 0-13-010778-6.  Edition 1 is available via FTP on
    cs.widener.edu in the tar file zen-1.0.tar.Z. [I think]

Further, this is primarily oriented towards UNIX email systems.
This is unfortunate, because it would be nice to have a general
document covering email in all of its forms.  However, each
operating system tends to have radically different email mechanisms,
so it would be difficult to do justice to any other environment.
It seems more useful to cover one environment well here, and have
companion documents for other environments.  Speaking of which,
why hasn't anybody else stepped in to do FAQs on other environments?
Like DOS, Mac etc.

And finally, this document is not intended to be pedantically
correct.  Knowledgeable readers will know that I'm glossing
over a lot of detail, and absolute precision has been balanced
against readability and effectiveness in helping people get
going.

--------
~Subject: Layout

This FAQ is laid out in the following sections:

    + An overview of how mail systems go together.

    + A glossary of the important terms to know.

    + A list of general do's and don'ts of mail systems.

    + Configuration Issues

    + Several suggested mail configurations.

    + General overviews of specific software.

--------
~Subject: Electronic mail - A General Overview of Structure

Electronic mail generally consists of three basic pieces:

    1) The link level transport - which could be
       UUCP, TCP/IP, or a host of others.  We'll call
       this the "transport medium" (TM)

    2) the "Mail Transport Agent" (MTA) which is responsible for
       transporting mail from source to destination, possibly
       transforming protocols, addresses, and routing the mail.

       The MTA often has several components:
        - Routing mechanisms
        - Local delivery agent (LDA)
        - Remote delivery agent
       Many MTA's have all of these components, but some
       do not.  In other cases, it is possible to replace
       certain components for increased functionality.

    3) The "User Agent" (UA) is the user interface -
       the software that the user uses to read his mail,
       sort things around in folders, and send mail.
       Sometimes called "Mail User Agent" (MUA).

--------
~Subject: Glossary

Rather than alphabetic, this glossary tends to group terms
referring to similar functionality together.

Transport Medium:

    UUCP (Unix to Unix Copy Program):
    Back in the mists of time, UNIX systems communicated only
    over RS232 serial lines, usually over modems.  UUCP is a
    suite of programs developed back in the early 70's to
    provide this communications link.  All that UUCP does is
    transfer files from one system to another.  There is an
    additional mechanism where one system can direct the
    destination system to run a file through a specific program.
    Electronic mail in UUCP is simply requesting the destination
    machine to run "mail" on a data file.

    UUCP communicates by means of "protocols", the most common
    being "g", a method for transmission of data over telephone
    lines and ensuring that the data is not corrupted.  There
    are several other protocols, none universally available,
    and most oriented towards communication media other than
    telephone voice lines (such as dialup X.25, PAD X.25, or
    LAN connects).

    UUCP operates over fixed system-to-system links, so sending
    mail from one system to another often has to traverse
    other intermediate systems.

    TCP/IP (Transmission Control Protocol/Internet Protocol):
    TCP/IP is a protocol that allows any system on a network to
    talk "directly" to any other, by passing packets of
    information back and forth.  TCP/IP (and its later relative
    OSI) is usually used over networks built on top of Ethernet,
    Token-Ring, Starlan and other LANS.

    SMTP:
    Or, "Simple Mail Transfer Protocol", is the communications
    protocol used most commonly over TCP/IP links in UNIX
    environments for mail.  SMTP usually operates directly between
    the source and destination machines, so intermediate machines
    don't get involved (except for gateways, see below).  SMTP
    is usually part of the MTA.

    SLIP (Serial Line Internet Protocol):
    SLIP is an implementation of TCP/IP designed for use over
    RS232 serial lines (ie: modems).  The other difference is
    that some SLIP implementations have the ability to "dial the
    phone" to make a connection for a specific transfer, whereas
    LAN TCP/IP is physically continuously connected.  You'd also
    need TCP/IP to run a SMTP mail connection.

    PPP (Point-to-Point Protocol):
    A successor to SLIP.

    X.25/X.29:
    X.25 is a packet switched data network which is usually
    half-duplex.  In this context, it's really an alternative
    to dialup over voice telephone lines with modems.  X.25
    is available in several "flavours", either direct X.25
    trunk connects over leased lines, through "PAD" interfaces,
    or by ordinary dialup modem access to X.25 "ports".

    To be useable in the context of mail transfers, you also
    have to use a file transfer protocol/mechanism of some
    sort on top of X.25.  The most common being UUCP "f" protocol
    (through PADS or dialup), or "x" with direct X.25 connects.

    Whether you use X.25 or phones plus modems depends on a number
    of factors - usually the determining factor is cost.  In North
    America, high speed modems (eg: 9600 baud and above) over telephone
    lines tends to be less expensive.  However, Europe's really
    wierd phone system structure usually makes X.25 more cost-effective,
    and therefore, X.25 use in UNIX mail systems is much more common
    in Europe than North America.

    X.29 is the command set used to configure and establish
    X.25 connections.

Networks:

    Internet:
    An "internet" is a network comprised of computers that talk
    to each other using TCP/IP, and usually SMTP for mail.

    The "Internet" is a vast network of hundreds of thousands of
    machines using SMTP protocol mail, communicating with
    each other over relatively high speed lines.  But not all
    "internets" are connected to *the* Internet.

    The Internet grew out of a US government funded project in
    inter-computer communications that grew into an enormous network
    of systems.

    One of the principle characteristics of this network is that
    machines are addressed by domain names which identify the
    destination, rather than addresses that are constructed out
    of the route from machine-to-machine-to-machine.

    UUCP Network:
    The UUCP network is that set of machines that talk to each other
    via UUCP.  Sending mail through this network requires that the sender
    know the network topology of UUCP links, and specify a path from one
    machine to the next.  (There are, of course, ways around this.
    See the section on "do's and don'ts".)

Mail addresses:

    Addresses:
    An email address is a method of specifying a given person on
    a specific machine.  There are scads of conventions, usually
    determined by the presence of "@"'s, "!"'s and other special
    characters in the name.  An address usually consists of
    two parts: a userid/name and a machine specification.

    A Domain address usually looks like:
        userid@domain-address
    Whereas a UUCP address usually looks like:
        siteA!siteB!siteC!userid

    Domain Addresses:
    Domains are a way of uniquely specifying a destination.
    Much like a postal address, a domain specifies a set of
    progressively more restrictive "domains" of the potential
    address space.  It would perhaps be illustrative to give an
    example:

        [e-mail]

    You read these things right to left: "com" means the
    commercial domain.  "fooinc" is the name of an organization
    within the commercial domain.  "Marketing" is the name of a
    suborganization within fooinc, and ferret gives the name of
    a machine (usually).  Domains can have any number of levels.

    The top level domain (com in the above example) has many
    possible values.  In the United States, "com", "mil", "edu",
    and "gov" are fairly standard.  Elsewhere, the top level
    domain tends to be a country code, the second level tends to
    be a province or state, OR a classification like "edu" or "ac"
    for academic (such as ac.jp, go.jp, ac.uk, edu.au, etc)
    and the third an organization.  But, for example, there are
    many .com and .edu sites in Canada and other countries.

    FQDN
    A fully-qualified-domain-name (FQDN) has a entry for each
    level of the domain, from individual machine to top-level
    domain.  In many cases, an organization has implemented an
    organizational "gateway" at a higher level of domain, so
    that people from outside don't have to specify FQDN's to get
    to a specific person.  In the above example, for instance,
    "fooinc.com" may be sufficient to get to anyone inside
    fooinc, and "ferret.marketing" may not be necessary.

    On the other hand, people sometimes leave out the higher
    levels of the address, as in "ferret.marketing".
    This is a bad idea - because if the mail is cc'd out of the
    organization, chances are the external recipient cannot reply,
    because "ferret.marketing" is incomplete.  So use addresses
    that are specified sufficiently for external users to use.
    (fooinc.com if a organizational gateway is used, the whole
    ferret.marketing.fooinc.com if not)

    NIC
    Internet TOP-LEVEL domains (edu, com, gov, mil) are controlled
    by a single organization, the NIC (nic.ddn.mil).  An organization
    "gets a piece" of the namespace by registering with the NIC, and
    then they are free to administer their own namespace (everything
    under fooinc.com) as they choose.  The same is true for foreign
    countries; Once they have their top-level domain (usually the
    two-letter ISO country code) registered with the NIC, they do
    the rest, and divide it as they see fit.

    In contrast, on UUCPnet, all machine names everywhere share a
    single flat namespace.  So it is important to choose a name
    that has not been used before. (See do's and don'ts).  This is
    why FQDN's help.  We can tell the difference between
    ferret.fooinc.com and ferret.blah.edu by their full names.
    (Instead of UUCP paths which may turn out to be wrong, and
    autorouting will probably send the mail to the wrong machine)

    MX record:
    A non-SMTP/Internet site that wishes to register on the Internet
    will need to get a "nearby" Internet site to set up a MX
    record for them.  An MX record is essentially a domain-server
    database record that (effectively) registers your domain name
    on the Internet, and indicates that the Internet site knows
    how to forward mail to you.  Usually via some non-SMTP/Internet
    route, such as UUCP.  You can get an MX record for one site, or
    a "wildcard" MX record so that you can have your own subdomains.

    Bang-Paths:
    With UUCP mail, the MTA has to specify a route to get from one
    machine to another.  "A!B!C!userid" means go to machine A,
    then B, then C, then user "userid" on C.  You should strive,
    however, for a MUA that allows you to use domain addressing,
    and let the MTA figure out the bang routing as appropriate.

Miscellaneous:

    Gateways:
    There are several meanings of this term, only two are relevant
    here.

    The first is a mechanism for getting from one network to another
    network that uses different protocols.

    The second is a mechanism for getting from one logical (often
    organizational) network to another using the same protocol.
    Often for example, there will be a LAN in one department of
    an organization, and one machine in the LAN has the connection
    to another LAN in another department.  This means that mail from
    one LAN to the other has to pass thru the gateway machine.

    Routers:
    There are several definitions, but the most important is that
    part of the TA that figures out how to send a message to
    a given machine.  This often uses a database that provides
    routes from one machine to the other machines on the network.

    Smarthost:
    In many cases, your machine won't know how to get to a specific
    destination.  You can usually set up your mail system to send mail,
    that it doesn't know how to deliver, to a machine that is more
    likely to.

    RFC's:
    A set of documents that include formal descriptions of mail
    formats used on the Internet, and are adhered to by many
    non-Internet systems.  More specifically, in the "worldnet"
    of USENET, Internet and UUCP, the RFC's set the standards
    for mail exchange.  RFC822, 1123 and 976 are the most important
    for Internet/UUCP mail.

    It should be pointed out, however, that there are some
    regions where the RFC's are not entirely respected.  For example,
    the British academic email networks (JANET) uses domains, but
    they're specified backwards (they drive on the wrong side of
    the road too ;-).

    MIME:
    Mime is the official proposed standard format for multimedia Internet
    mail encapsulated inside standard Internet RFC 822 messages.  Facilities
    include sending multiple objects in a single message, character sets
    other than US-Ascii, multi-font text messages, non-textual material
    such as images and audio fragments, and other extensions.  For an
    overview of Mime, see ftp.uu.net:mail/metamail/MIME-overview.txt.Z.
    The defining document is Internet RFC 1341: N Borenstein & N Freed,
    ``Mime (Multipurpose Internet Mail Extensions) mechanisms for specifying
    and describing the format of Internet message bodies'' (June 1992).
    Also see RFC 1344: N Borenstein, ``Implications of Mime for Internet
    mail gateways'' (June 1992).

    Mime covers only message bodies, not message headers; to see how to
    represent non-Ascii characters in message headers, see Internet
    RFC 1342: K Moore, ``Representation of non-Ascii text in Internet
    message headers'' (June 1992).

    X.400:
    A CCITT standard for email formats, more or less an alternative
    to RFC 822/976/1123.  This format will probably start taking over
    from RFC 822/976/1123 mail.  It is likely to (already has?) become an
    ISO/IEEE standard along with OSI etc.

    "The Maps":
    A set of files describing machine-to-machine links distributed
    over USENET in the group comp.mail.maps.  These are usually posted
    on a monthly schedule, and can be automatically received and
    transformed into a routing database that describes the "optimal"
    route to each machine.  These are operated by the "UUCP Mapping
    Project".  See the README posted along with the maps for
    more details.

    Aliases:
    Aliases are a mechanism by which you can specify the destination
    for mail on your machine.  Through the use of aliases you can
    redirect mail to "virtual userids".  For example, you should
    have a mail destination on your machine called "postmaster", which
    is aliased to send the mail to the System Administrator (ie: you
    probably).  Aliasing often also permits you to send mail to groups
    of users (not necessarily on the same machine as you) pipelines of
    commands or to specific files.

    Mailing lists:
    Are similar to USENET newsgroups.  They are usually aliases
    pointing to groups of users, and allow mail to be sent to the
    whole group at once.  Mailing lists are set up to carry certain
    subjects.  The difference between a mailing list and a USENET
    newsgroup is that the messages are sent by mail, probably as
    a copy to each recipient, rather than broadcast.

--------
~Subject: Do's and Don'ts:

1) Register a domain name.  Even on UUCP, where <machine>.UUCP is often
   used as a kludge, it is MUCH preferred that you obtain a real
   domain address.  If you are directly connecting to the Internet,
   you will get one as part of your registration with the NIC.

   If you aren't connecting directly to the Internet, obtaining a
   registration will usually require you finding a nearby friendly
   Internet site willing to act as a mail forwarder to you from
   the Internet - the site that will set up a "MX record" for you.
   Many sites will do this for you for free, and several of the
   commercial email services (eg: uunet) will do it for you for a
   nominal charge (without requiring you buy the rest of their
   services).

   There are occasions where you can join what is called a "domain
   park".  These are most often small regional groups of systems that
   have gotten one of their number properly registered as a domain,
   and provides forwarding services out to other systems.  For
   example, in my address "ferret.ocunix.on.ca", "ocunix.on.ca"
   is a domain park made up of the Ottawa-Carleton UNIX User's Group,
   one of the other machines in the group provides a gateway between
   our systems and the Internet.

2) If your machine is going to "speak" UUCP to the outside world,
   choose a unique UUCP name.  You can find out whether a name you
   want is taken by consulting the UUCP maps.  Or by asking someone
   else who's using them.

3) Register your machine with the UUCP Mapping Project.  Information
   on how to do this is included in the monthly maps postings in the
   file "README".  This is usually only required when your machine
   talks UUCP to the outside world, or when other machines have
   to address you by your UUCP name.  If you don't do this, somone
   else may choose the same name, and gross confusion will arise
   when smart routers won't be able to tell whether to send a piece
   of mail to you, or your doppelganger[s].  If you register with the
   UUCP Mapping Project, you have prior use, and people who choose
   the same name afterwards will be told to get a new one.

   If you're "behind" an organizational gateway, don't do this.
   (Your organizational gateway is the thing that needs to be
   registered)

   If you do fill in a map, please take the time to fill it in
   carefully, giving contact people and phone numbers.  Just in
   case your machine goes crazy and starts doing something nasty.
   Note expecially the latitude and longitude.  Get it right,
   or omit it.  Brian Reid gets really annoyed with sites that
   are half a world away from where they really are.

3) If you're going to be setting up multiple machines, have only
   one or two connections to the outside world.

4) Install a mail system that understands domain addressing, even
   if you aren't registered.  (In fact, all of the suggested
   configurations in this FAQ do)

5) *Never* use UUCP bang-routing with the MUA if you can possibly
   avoid it - each of the suggested mail configurations provide
   mechanisms where you, the user, do not have to specify routes
   to the MUA - you can specify domains, and the TA will do the
   routing (possibly bang-routing) for you.

6) Find a friendly neighboring SA to help.  A SA who has already
   operating mail in your area will help smooth over the regional
   "gotchas" that are bound to crop-up.  And advise you on the
   right software to use, where to obtain it, and how to install it.

7) Do NOT use "any old" Map unpacking program.  Most available
   map unpacking programs automatically run the shell (or shar)
   to unpack map articles.  Since it is trivially easy to forge
   map articles, using this type of unpacking program can
   easily let very destructive trojan horse or virus programs
   into your machine.

   The two specific map unpackers described in this FAQ are known
   to be secure from such attacks.  Do not run any other unpacker
   unless you are aware of the issues and can inspect the code for
   such vulnerabilities.  [If you know of other "secure" map
   unpackers that are generally available, please let me know]

--------
~Subject: Configuration Issues:

What you need for email connectivity is determined by:

    1 What networks you intend to connect to.
      The Internet (hence SMTP)?  UUCP sites?  X.400?
      Bitnet?  Others?  Combinations?
    2 What links you have or are willing to install
      Internet T1?  T2?  UUCP?  Other?  [Details on how to
      make your connections is beyond the scope of this FAQ,
      but can usually be found out from the provider (other end)
      of the link]
    3 what user interface you want to use.  This is largely
      an independent issue, so consult the Specific Package
      Reviews directly.

--------
~Subject: Recommended MTA Configurations:

These configurations are based upon my own experience, and the
experience of others.  Careful installation of any of these
configurations will result in a solid, reliable mail system
that respects the appropriate "do's and don'ts".  Each configuration
represents a compromise of ease of installation and maintenance
versus sophistication and capabilities.

One thing you should consider is what you already have on your
system.  You will invariably have "binmail", and will have a good
chance at already having sendmail.  Some systems come with
smail (if 2.3, junk it)  The configurations shown below are *minimal*
configurations, so you should consider whether you want to use what
you already have or not.

Scenario 1:  Only UUCP connections.

    Smail 2.5.  If you want to set up a routing database of
    your own, you will also need pathalias, and unpackmaps or
    uuhosts.  Instead, though, you can configure smail 2.5 to
    smart-host most destinations to a nearby friendly site
    who'll do your routing for you without having to run
    the routing software.  Note further, that you can run
    pathalias on just a subset of the full set of maps.
    [Unpackmaps makes this particularly easy to do]

    Smail 2.5, as shipped, does not support mail-to-pipeline
    or mail-to-file aliasing.  If you need these, at a minimum,
    you should obtain lmail.  If you intend more than casual
    use of these features, it is recommended that you obtain
    deliver instead of lmail.

    Even if you have sendmail already, you can integrate smail 2.5
    with it to do your UUCP routing.  (though, some later versions
    of sendmail can do routing themselves)

    (See the note regarding smail 2.7 in the Package Reviews)

Scenario 2:  SMTP connections (optionally, some UUCP connections too).

    Generally speaking, sendmail will do this for you and you have
    a good chance to have it already.  However, for the novice, it
    is recommended that smail 3 be used instead [see review of
    sendmail below].  Smail 3 includes all of the routing software
    and can do mail-to-pipeline and mail-to-file, so none of the auxiliary
    programs mentioned in scenario 1 are necessary.

    Most sendmails don't include UUCP routing mechanisms, so you would
    need pathalias and unpackmaps or uuhosts if you wish to set up
    a UUCP routing database.  Further, most sendmails don't know
    how to query a pathalias database directly, so you may have to hack
    your own path lookup program into the sendmail.cf (smail 2.5 can
    be used for this purpose provided that you will have a UUCP link
    to the outside world)

    Both MMDF and PP can also be used.

    Deliver or procmail are still quite useful in this configuration
    for extended alias facilities.

Scenario 3:  Connections to other networks (optionally including
    SMTP or UUCP), or very high loading.

    Your best bets are MMDF, PP or zmailer.

    You can implement other network interfaces with sendmail, but
    not only will you probably have to roll your own, but sendmail
    can't cope with high loading very well.  Ditto smail 3.

There are other configurations.  See the Package Reviews to
determine which packages are appropriate.

--------
~Subject: Package Reviews

Honesty requires me to point out which software packages were
reviewed by their author (including me ;-).  I do so by appending
a "*" to the name of the author.  In some cases, the material
has been cribbed from FAQ's or general information blurbs.

It is worth noting, though, that most of these packages are well
known, and have been in operation at many sites for periods of
a year or more.  These packages do their job well, and have been
extensively thrashed out in the best debugging laboratory in the
universe (USENET ;-)

A few packages have been mentioned prior to their release.
(Smail 2.7, unpackmaps 4, the occasional beta version).  It is
recommended that these versions be avoided by novices until they
have had a chance to settle for a little while.  This FAQ will
note when such software seems (according to rumour *I* hear) to be
stable enough for general use.

Some of these packages are capable, by various bits of hackery,
of doing a lot more than is claimed for them.  But I refrain
on telling you how to "take the covers off".  Given the
intended audience, that would be tantamount to trying to
teach preschoolers do-it-yourself brain surgery.  Please don't
take this as condescending - I've been working on/in/with email
systems for over 12 years and I *still* won't play with (as
just one example) sendmail.cf's.

Therefore, I restrict myself largely to "out-of-the-box" functionality,
"fill-in-the-blank" configurability, and normal documented installation
procedures.  Beyond that, you're on your own.

binmail

    binmail is usually really called "mail". On System V prior to
    Release 4, it is a really simple UA that does dual duty as the
    TA.  It's pretty awful because it doesn't know how to set up
    headers properly, doesn't even know what a "Subject:" line is,
    and there's no way to do any kind of aliases.

    On BSD, binmail invokes sendmail to do the MTA function.  On
    System V prior to Release 4, you really do want to replace binmail's
    MTA functionality with something else.  However, you should not
    replace it in its "mail" (UA) functionality, because many
    system-level administration mechanisms will break.  Any new UA
    should be installed as a different name than "mail".

    Beginning with System V Release 4, "binmail"'s transfer agent
    capabilities were considerably enhanced to have similar capabilities
    to Smail 3 and sendmail.  There is usually no need to replace it with
    another mail agent.  (See SVR4 mail discussion below)

    Binmail stores mail in "mbox" format.

rmail

    binmail's TA functionality is implemented by linking mail
    to rmail.  It's rmail that you'd want to replace with smail 2.5
    etc.

Mail

    The original BSD UA.  It can support local profiles, aliases, folders,
    header previewing, out-going mail recording and all sorts of good stuff.
    An "okay" UA.  Available from BSD "freed-sources" archives.

    Mail stores mail in "mbox" format.

mailx

    AT&T's answer to BSD "Mail", from which it is descended.  Some versions,
    such as the 3b1 one, should be avoided because of a buggy port.  Not
    available in source form (it's proprietary but ubiquitous enough to be
    mentioned here).

    Mailx stores mail in "mbox" format.

mush: author Dan Heller* <[e-mail]>

    The "Mail User's Shell" is a "shell" for mail users.  That is, it
    has its own environment where you can configure not only the user
    interface, but the actual internal mechanisms.  Internally, mush
    has a csh-like scripting language, altho it's not as powerful as
    csh.  It has command-line aliases, file completion, if-else state-
    ments, command piping, and so on.  Because you can build your own
    commands, you can virtually build your own library of email features.

    Mush has two tty-based interfaces: the standard tty-mode (ala BSD
    Mail or sys-v mailx) and the fullscreen/curses mode (ala vi, emacs
    or even Elm).  You can set up key bindings that execute one or more
    mush commands, personalized commands or even UNIX commands.  You
    can even emulate keyboard input with keyboard macros and mappings.

    Mush also has a SunView interface that is more powerful than Sun's
    Mailtool, yet backwards compatible with most versions.  Most sunview
    users (if there are any left these days) prefer MushView over Mailtool.

    The current version of Mush is 7.2.3, last posted in comp.sources.misc
    volume 18 (with subsequent patches).  All three interfaces are
    available in one runtime binary.  Except for the MushView interface
    (which is only available on for suns), Mush is portable to everything
    that runs UNIX.  There is also a DOS port available for PCs and can
    run on most 286 machines. An older version of Mush (6.5) can run on
    as little as 640 of RAM.  (Mush-PC is typically used with UUPC.)

    The "next generation" of Mush is a commercial product called Z-Mail
    from Z-Code Software (mail [e-mail] for details).  All aspects
    of Mush are retained, yet it has grown to be far more powerful.  It
    runs under X windows with either a Motif or Open Look interface
    and also supports multi-media, user "functions" and a suite of new
    features.

    Third party documentation is available from O'Reilly in the book
    entitled "The Z-Mail Handbook" (by Hanna Nelson).  This book not only
    covers Z-Mail, but Mush as well.

    Mush stores its messages in "mbox" format, or MMDF format if you're
    using MMDF as your MTA.

    The newsgroup comp.mail.mush is dedicated to it.

    [Note: Z-Mail is not related at all to Zmailer.  Zmailer is a MTA]

elm: coordinator Syd Weinstein* <[e-mail]>

    (cribbed from comp.mail.elm FAQ)

    Elm is designed to run with "sendmail" or "/bin/rmail"
    (according to what's on your system) and is a full
    replacement of programs like "/bin/mail" and "mailx".  The
    system is more than just a single program, however, and
    includes programs like "frm" to list a 'table of contents'
    of your mail, "printmail" to quickly paginate mail files (to
    allow 'clean' printouts), and "autoreply", a systemwide
    daemon that can autoanswer mail for people while they're on
    vacation without having multiple copies spawned on the
    system.

    The most significant difference between Elm and most other
    mail systems is that Elm is screen-oriented.  Upon further
    use, however, users will find that Elm is also quite a bit
    easier to use, and quite a bit more "intelligent" about
    sending mail and so on.

    Current release is Elm 2.3 PL11, comp.sources.unix vol 22, issues
    60-85.  Patches in c.s.u vol 24, issue 25-35.  Patches are also
    available from the archive server at DSI.COM:
    send mail to [e-mail]
    send elm index

    [Ed: elm is particularly good for novices.  The only drawback
    that I've heard is that elm is a bit less user configurable than,
    say, mush]

MM: Contact Joseph Brennan* <[e-mail]>
                Columbia University in the City of New York

    (cribbed from MM man page.)

    mm is a powerful electronic mail system which allows you to send, read,
    edit and manage messages quickly and easily.  It is designed to have the
    same interface as the MM program written and developed for DEC20s over a
    period of many years.

    mm was written using the CCMD package developed at Columbia.  Thus, it
    has copious internal help, completion of partially typed commands on use
    of the TAB key, and help on partial commands when ?    is typed.

    mm can read several mail-file formats.  Its default is mbox, the same
    format used by unix mail.  It also can read babyl, used by emacs rmail,
    and mtxt and MH.  It can copy messages from one file type to another.

    MM is a Freeware MUA copyright by Columbia University (as is this
    description).

    MM is available by anonymous ftp from cunixf.cc.columbia.edu, directory mm.
    The file mm-intro.txt there is a longer description of how it was developed.

    [Ed: MM also appears to be a good UA for novices.  From the examples
    in the manual page, it handholds extensively and is not screen oriented.]

MH: Maintainer John Romine <[e-mail]>

    The big difference between MH and most other "mail user agents" is
    that you can use MH from a UNIX shell prompt.  In MH, each command
    is a separate program, and the shell is used as an interpreter.  So,
    all the power of UNIX shells (pipes, redirection, history, aliases,
    and so on) works with MH--you don't have to learn a new interface.
    other mail agents have their own command interpreter for their
    individual mail commands (although the mush mail agent simulates a
    UNIX shell).  Mail messages are stored in individual files.

    The current version of MH is 6.7.2.  MH comes standard with Ultrix
    4.0 and later, and AIX 3.1 and later.
    via anonymous ftp:
    ics.uci.edu [128.195.1.1]      pub/mh/mh-6.7.tar.Z    1.6MB
    louie.udel.edu [128.175.1.3]  portal/mh-6.7.tar.Z    1.6MB

    A new version of MH that supports multi-part multi-media
    mail is currently in alpha-test.

    comp.mail.mh discusses MH, and contains a FAQ article.

GNU Emacs Rmail:

    Rmail is an Emacs subsystem for reading and disposing of mail.  Rmail
    stores mail messages in Rmail files in BABYL format (originally used
    under the ITS operating system), although it can incorporate new mail
    from MMDF and Unix format files, or mixed-format files.  Reading the
    messages in an Rmail file is done in a special major mode, Rmail mode,
    which redefines most letters to run commands for managing mail.

    Rmail can do the standard things such as displaying, deleting, filing,
    or replying to messages.  Replying uses another Emacs subsystem, Mail
    mode.  Messages can be saved in either BABYL or Unix format.  Rmail
    maintains per-message attributes and user-defined labels.  Rmail can
    burst message digests.

VM: Author Kyle Jones* <[e-mail]>

    VM (View Mail) is a GNU Emacs subsystem that allows UNIX mail to be read
    and disposed of within Emacs.  Commands exist to do the normal things
    expected of a mail user agent, such as generating replies, saving
    messages to folders, deleting messages and so on.  There are other more
    advanced commands that do tasks like bursting and creating digests,
    message forwarding, and organizing message presentation according to
    various criteria.

    The current version of VM is VM 4.41.
    FTPable from:

    ab20.larc.nasa.gov        pub/vm/vm-4.41.tar.Z
    ftp.uu.net            pub/vm-4.41.tar.Z
    archive.cis.ohio-state.edu    pub/gnu/emacs/elisp-archive/packages/vm-4.41.tar.Z

    VM is discussed in gnu.emacs.vm.info, or by mailing list by sending
    an e-mail request to [e-mail].

MH-E: Maintainer: Stephen Gildea <[e-mail]>

    MH-E is an interface to MH from within GNU Emacs.  It helps if MH was
    compiled with the MHE compiler flag.  MH-E is distributed with both GNU
    Emacs and MH.  Choose the later version.

C-Client: Author Mark Crispin <[e-mail]>

    Software writers only:

    C-client is a general library useful for creating MUA's.  It provides
    a high level logical interface for retrieving and manipulating
    mail messages.  It supports the latest draft of MIME (proposed
    Internet standard for multipart, multimedia, typed electronic mail).
    It is driver based, and easily ported to new platforms and MTA's,
    already supports BSD, SysV, DOS, Macintosh and TOPS-20(!),
    and supports present mail and mailbox formats.

    Just the thing if you want to write a new MUA.

    Contact the author for more details.

Metamail: Author N. Borenstein
    [Described by Paul Eggert, [e-mail]]

    Metamail is a software implementation of Mime, designed for easy
    integration with traditional mail-reading interfaces -- typically,
    users do not invoke metamail directly.  Ideally, extending the local
    email or news system to handle a new media format is a simple matter
    of adding a line to a mailcap file.  Mailcap files are described in
    RFC 1343: N Borenstein, ``A user agent configuration mechanism for
    multimedia mail format information'' (June 1992).  The source code
    for metamail can be found in ftp.uu.net:mail/metamail/mm.tar.Z.
    To join its mailing list, write [e-mail].


MailManager: Author Mark Crispin <[e-mail]>

    A MUA implemented using C-Client for NeXT computers.

Pine: Authors Lundblade, Seibel, and Crispin <[e-mail]>

    Pine is a mailer developed by the University of Washington Office of
    Computing and Communications. It has been designed for ease-of-use and
    with the novice computer user in mind. It is based on Internet mail
    protocols (e.g. RFC-822, SMTP, IMAP, and MIME) and currently runs on
    a variety of UNIX platforms.

    The guiding principles for achieving ease-of-use in Pine were:
    careful limitation of features, one-character mnemonic commands,
    always-present command menus, immediate user feedback, and high
    tolerance for user mistakes. It is intended that Pine can be learned
    by exploration rather than reading manuals.

    A stand-alone version of Pico, Pine's message composition editor, is also
    included. It is a very simple and easy to use text editor with text
    justification and a spelling checker.

    Features:
       - Mail index showing a message summary which includes the status,
     sender, size, date and subject of messages.

       - View and process mail with the following commands:  forward, reply,
     save, export, print, delete, capture address and search.

       - Address book for saving long complex addresses and personal
     distribution lists under a nickname.

       - Multiple folders and folder management screen for filing messages.

       - Message composer with easy-to-use editor and spelling checker.
     The message composer also assists entering and formatting
     addresses and provides direct access to the address book.

       - Online help specific to each screen and context.

       - Supports access to remote mail repositories via the IMAP2 protocol
     defined in RFC-1176.

       - Soon to support multi-part mail conforming to proposed MIME Internet
     standard, allowing sending of sounds, graphics such as GIF and TIFF
     files, and binary files such as spreadsheets.

    Pine, including source code, is freely available via anonymous FTP from
    ftp.cac.washington.edu on the Internet. Other provisions for distribution
    have not been made. From the Internet, you may try out Pine and leave
    comments by telneting to "demo.cac.washington.edu" and logging in as
    "pinedemo". To join the Pine mailing list for announcements send a
    request to "[e-mail]".

    Pine is very portable and runs on a variety of UNIX machines including
    DECstations, NeXTs, VAX's and Suns. Pine was originally based on Elm,
    but it has evolved much since, ("Pine Is No-longer Elm").

    For further information send e-mail to [e-mail]. Pine is
    the work of Mike Siebel, Mark Crispin, and Laurence Lundblade at the
    University of Washington.

uumail:

    Uumail is a very old and obsolete precursor to smail 2.5.  Included
    here only because I know that uumail sites still exist.  You
    should not install uumail in new configurations, and existing
    uumail sites should convert to something more modern.

smail 2.5: author The UUCP Mapping Project

    Smail 2.5 is a small, simple and hard-coded rule MTA for use on
    UUCP networks.  It understands RFC compliant headers, will
    generate RFC compliant Internet-style headers, can
    use domains, aliases, a pathalias UUCP routing database, and
    is very simple to install.  For full functionality, you will
    also want pathalias and a map unpacker.  The one thing
    it cannot do by itself is mail-to-pipe and mail-to-file aliasing.
    For that, you need Zeeff's lmail, deliver or procmail (see
    note on procmail).

    Smail 2.5 has the capability of coalescing addresses into single
    UUCP transfers, and knows how to query UUCP for the names
    of UUCP neighbors, and autoroute if necessary.

    Smail 2.5 has a few bugs that are (usually) pretty rarely seen
    in operation.  There have been a number of patches posted for it,
    but it is recommended that you do not apply them - some were
    ill-conceived, buggy in their own right, or conflicting with others.
    The only patches that I feel safe in recommending is Chip
    Salzenberg's patches for use with Xenix MICNET - which are
    unnecessary unless you are in the unfortunate position of having
    to actually *use* MICNET.  In particular, do not apply the
    "mail-to-pipe/file" patches that float around for smail 2.5.
    This is a major security hole.  If you're concerned about the bugs,
    I suggest you wait for smail 2.7.

    Smail 2.5 can also be used with sendmail as a UUCP router.

    Smail 2.5 was posted in comp.sources.unix in 1987, volume 18.

smail 2.7: custodian Greg Woods <[e-mail]>

    Smail 2.5 was originally a dead end.  There was a smail 2.6 used
    internally in some places (no, don't ask for it).  Greg Woods
    is doing a major cleanup and revision of smail 2.[5-6] (with permission
    of the authors) and will be releasing it (I hope) soon.  Smail 2.7
    will be, more-or-less, a version of smail 2.5 with all bugs eliminated,
    and lmail's functionality rolled in.  It will probably include
    the latest pathalias, and possibly a new revision of unpackmaps.

    Watch this space for late-breaking news ;-)

lmail: Author Jon Zeeff <[e-mail], [e-mail]>

    When you install smail 2.5, you link the original /bin/mail (binmail
    above) to /bin/lmail to perform the task of actually delivering the
    mail to the user's mailbox (LDA).

    Since smail 2.5 was not capable of doing mail-to-pipe and mail-to-file
    aliasing, Jon Zeeff wrote a replacement lmail that implemented
    these (along with user mailbox delivery).

    Jon's program is okay for casual use, but has some pretty serious
    bugs.  Fixed versions are available, but you're probably better
    off waiting for smail 2.7, or installing deliver or procmail.

smail 3: Author Ronald S. Karr* <[e-mail]> and Landon Curt Noll.

    Smail3.1 is a domain-capable mail router and delivery program that
    works in the UUCP zone and on the Internet and that is capable of
    gatewaying between the two.  It was written primarily by me (Ronald
    S.  Karr) and Landon Curt Noll, with the blessings of the original
    Smail1 and Smail2 authors.

    Smail3 supports SMTP, UUCP mail, alias files, .forward files, mailing
    list directories, pathalias files, /etc/hosts files, the domain name
    system, and can also query uucp for neighboring sites, automatically.
    It also supports use of encapsulated SMTP commands for delivery over
    UUCP connections, which allows batching of multiple messages into a
    single UUCP transaction, and allows many addresses to be passed with a
    single message transfer, which can greatly decrease the traffic
    generated for large mailing lists.  It is also very simple to configure
    with a reasonable certainty of correctness.

    Smail3 includes pathalias and a reliable map unpacker.

    Rather than using configuration files to resolve addresses based on
    their syntax, ala sendmail, Smail3 uses a database metaphore for
    resolving addresses based on their contents.  The set of methods that
    Smail3 uses for resolving local addresses and hosts is configurable and
    extensible.  Smail3's methods for parsing addresses are not
    configurable.  It is the opinion of the authors that addressing on the
    Internet and in the UUCP zone has become sufficiently standardized that
    attempts to allow configurability in this area are now a hindrance to
    the correct working of the network.

    Current releases of Smail3 have some problems when operating on the
    Internet or on local ethernet networks.  Some of the problems arrise
    when when the level of traffic gets too high, and result from the fact
    that Smail3 does not currently limit its usage of CPU resources.
    Additionally, Smail3 is not yet sufficiently intelligent in its
    management of outgoing SMTP connections.  As a result, Smail3 does not
    make effective use of single connections, and cannot use a history of
    connection failures to alter its behavior.  These problems are now
    being addressed.

    Questions related to Smail3 are usually discussed in comp.mail.misc.
    There are also two discussion mailing lists.  To join the mailing
    lists, send mail to:

    [e-mail]

    The current release of Smail3 can be found on uunet, in the directory
    /usr/spool/ftp/mail.  The current release file is smail-3.1.25.tar.Z.

    Smail 3 is covered under the GPL (if it matters)

sendmail: Original author Eric Allman

    Sendmail is the granddaddy of all intelligent MTA's.  It can do just
    about anything.  It's main problem is that it can do just about
    anything.  Modification of sendmail's configuration tables (which is
    necessary with most vendor-supplied versions) is NOT for novices.
    The language of the sendmail.cf is cryptic, but that isn't really
    the problem (and this problem can be solved by using "EASE", a
    sendmail.cf writing language, or the UIUC IDA kit's configuration
    file building tools).  The problem is that it's extremely difficult
    to know when the rules you are implementing are the right thing--
    many sendmail configurations do slightly buggy, or even extremely
    buggy, things (eg: some major mail gateways munge From: headers in
    illegal ways).  (The default configurations generated by the UIUC
    IDA kit are, however, very good at Doing the Right Thing under most,
    if not all, circumstances.)

    Worse, every vendor's version of sendmail is different, and many
    of their sendmail.cf's don't work at all  (HPUX is one example
    of where the sendmail.cf is actually pretty sane.  HP is to
    be congratulated.  On the other hand, some vendors, who shall
    remain nameless, can't even get their sendmail to speak SMTP
    on a LAN).

    There are several versions of sendmail extant in the world.  There
    is no "latest" version.  If you want to use sendmail, it is strongly
    recommended that you obtain "IDA sendmail".  The IDA version is much
    more likely to do the right things with mail coming from, or
    ultimately going to, UUCP sites and is much easier to maintain.  IDA
    sendmail can handle pathalias-style UUCP routing quite well.  The
    impending release of BSD 4.4 includes a new version, 6.1, of sendmail.

    I am being a bit overly harsh on sendmail.  If you obtain a good
    configuration (like the aforementioned HPUX version), or are willing
    to spend the time to learn it, sendmail will do what you want.
    Well.  IDA sendmail is STRONGLY recommended.  The latest version of
    IDA sendmail is 5.65c, and 5.65d is in beta test.  5.65c is
    available for FTP from ftp.uu.net and uxc.cso.uiuc.edu.  Paul Pomes,
    <[e-mail]>, is controlling the IDA Sendmail releases.

    Sendmail is discussed in comp.mail.sendmail.

    EASE version 3.5 was posted in volume 25 of comp.sources.unix and
    is available from wuarchive.wustl.edu [128.252.135.4] (directory
    /usenet/comp.sources.unix/volume25/ease) and many other c.s.u
    archives.

ZMailer: Author Rayan Zachariassen* <[e-mail]>

    ZMailer is intended for gateways or mail servers or other large site
    environments that have extreme demands on the abilities of the mailer.

    Code and Design features:

    + Strong limits on host impact.
    + Secure design (and hopefully implementation).
    + Natural fit for client/server environments.
    + Extremely customizable configuration mechanism.
    + Flexible database interface with support for: sorted files, unsorted
      files, dbm, ndbm, gdbm, nis (yellow pages), dns (BIND resolver),
      /etc/hosts file, and in-core data.
    + Efficient message queue management.
    + Fast binary-transparent SMTP server and client.
    + Low-technology implementation.

    Default configuration file features:

    + Default configuration will work for most sites.
    + Network protocol support for: smtp, uucp, bitnet, mail to news.
    + An easy way of overriding any external routing information.
    + Automatic handling of mailing lists.

    It is available by anonymous FTP from ftp.cs.toronto.edu:/pub/zmailer.tar.Z
    or ftp.cs.toronto.edu:/distrib/zmailer.tar.Z.

MMDF [reviewed by [e-mail]]

    MMDF is a MTA. It works on the principle that you have communications
    channels, both incoming and outgoing, and it arranges for messages to
    pass between them.

    Strong points include:
    * Ability to turn up and down debugging level on the fly
    * Very strong on authentication, and permission checking.
    * Can block mail based on who it came from, how it got there,
      who it is going to.

    It is older than sendmail, simpler than sendmail, and it is a great
    pity that it was not shipped as standard instead of sendmail.

    It has one major advantage to people in the UK, in that it knows how to
    handle mail addresses in our 'correct' format (Most significant part first,
    e.g. net.uu.uunet), as well as the thing the rest of the world uses :-) :-)

    The accepted wisdom is that MMDF should be replaced with PP, since PP
    is the descendent of MMDF.  We are happy with MMDF, and for many years all
    the UK mail gateways used it.

PP: Author University College London

    PP is a Message Transfer Agent, intended for high volume message
    switching, protocol conversion, and format conversion. It is targeted for
    use in an operational environment, but may also be useful for investigating
    Message related applications. Good management features are a major
    aspect of this system. PP supports the 1984 and 1988 versions of the
    CCITT X.400 / ISO 10021 services and protocols. Many existing RFC 822
    based protocols are supported, along with RFC 1148 conversion to X.400.
    PP is an appropriate replacement for MMDF or Sendmail, and also supports
    SMTP and UUCP mail.

    For more information contact: [e-mail] or [e-mail]
    The latest version is PP-6.0, which was posted in comp.sources.misc,
    volume 27.

SVR4 mail: Author AT&T (description written by Tony Hansen,
    [e-mail])

    The System V Release 4 mail system is a domain-capable mail router and
    delivery program that works in the UUCP zone and on the Internet and
    that is capable of gatewaying between the two.

    SVR4 mail supports SMTP, UUCP mail, alias files, forwarding files,
    mailing list directories, /etc/hosts files, the domain name system, and
    can also query uucp for neighboring sites, automatically.  (System V
    Release 4.1 also allows batching of multiple messages into a single UUCP
    transaction, and allows many addresses to be passed with a single
    message transfer, which can greatly decrease the traffic generated for
    large mailing lists.)  It is also very simple to configure with a
    reasonable certainty of correctness.

    It also supports mail-to-pipe and mail-to-file.

    SVR4 mail uses configuration files to resolve addresses based on their
    syntax, somewhat similar to sendmail, but using regular expressions and
    a more easily understood syntax. The set of methods that SVR4 mail uses
    for resolving local and remote addresses and hosts is configurable and
    extensible.

    Questions related to SVR4 mail are usually discussed in comp.mail.misc.

    SVR4 mail is a standard part of System V Release 4; unfortunately, some
    vendors have not realized that SVR4 mail is not the same mailer as the
    SVR3 mail system, and have replaced it with other inferior mail systems.

deliver: Author Chip Salzenberg* <[e-mail]>

    Deliver allows any user to write a shell script that processes all
    incoming mail messages for that user.  The system administrator may
    also install scripts that process all messages by installing
    it as the Local Delivery Agent (lmail replacement).

    The output of a script is a list of mail addresses, files and programs
    that should receive the message.  It has access to each message as it
    is processed, so the action can be content dependent.  The script may
    also generate automatic replies, like the "vacation" program, or pass
    along a modified version of the original message.

    Deliver can be used to construct mail-based services (e.g. automatic
    mailing list maintenance).  It can also be used to filter mail
    automatically in prearranged ways (e.g. encryption and decryption,
    tossing junk mail, or vacation notices).

    Deliver was last posted in comp.sources.reviewed, volume 1.  The
    current version is 2.1.09.

procmail: Author Stephen R. van den Berg*
                <[e-mail]>

    Can be used to create mail-servers, mailing lists, sort your incoming mail
    into separate folders/files (real convenient when subscribing to one or
    more mailing lists or for prioritising your mail), preprocess your mail,
    start any programs upon mail arrival (e.g. to generate different chimes on
    your workstation for different types of mail) or selectively forward
    certain incoming mail automatically to someone.

    The accompanying formail program enables you to generate autoreplies,
    split up digests/mailboxes into the original messages, do some very simple
    header-munging/extraction, or force mail into mail-format (with leading
    From line).

    Procmail was designed to deliver the mail under the worst conditions
    (file system full, out of swap space, process table full, file table full,
    missing support files, unavailable executables; it all doesn't matter).
    Should (in the unlikely event) procmail be unable to deliver your mail
    somewhere, the mail will bounce back to the sender or reenter the
    mailqueue (your choice).

    A recent version can be picked up at various comp.sources.misc archives.
    The latest version (2.70) can be obtained directly from the ftp-archive at:
        ftp.informatik.rwth-aachen.de (137.226.112.31)
        as compressed tar file:         pub/unix/procmail.tar.Z         <128KB
        or in compressed shar format:   pub/unix/procmail.0?.Z

    [Ed note: I had noted reported difficulties in integrating procmail
    with System V and/or smail 2.5.  The 2.70 version of Procmail eliminates
    these difficulties.]

mailagent: Author Raphael Manfredi* <[e-mail]>

    The mailagent is yet another mail filter, written in perl, which will let
    you do anything with your mail. It has all the features you may expect from
    a filter: mailing lists sorting, forwarding to MTA or to inews, pre-processing
    of message before saving into folder, vacation mode, etc... It was initially
    written as an ELM-filter replacement, but has now enough power to also
    supplant MMDF's .maildelivery. There is also a support for @SH mail hooks,
    which allows you to automatically distribute patches or software via command
    mails.

    The mailagent was designed to make mail filtering as easy as it can be. It
    is highly configurable and fairly complete. Rules are specified in a lex-like
    style, with the full power of perl's regular expressions. The automaton
    supports the notion of mode, and header selection has many magic features
    built-in, to ease the rule writing process.

    The distribution comes with a set of examples, an exhaustive test suite,
    and naturally a detailed manual page. It should be noted that the mailagent
    will work even if your system administrator forbids "| programs" hooks in
    the ~/.forward, provided you have access to some sort of cron daemon.

    The mailagent program is available via anonymous FTP thanks to Christopher
    Davis <[e-mail]>:

    Host: ftp.eff.org (192.88.144.4),
    Directory: /pub/net-tools
    File: perl-mailagent.tar.Z

    Recently issued patches can be obtained directly from my mailagent (see
    instructions in the README file).

    [Ed note: while feasible to use this as an LDA, the author recommends against
    it.  Since it is written in Perl, it can cause rather severe performance
    problems on small machines, but it does try to regulate system impact.
    On high performance workstations, it should be a real winner.]

pathalias: Author Peter Honeyman

    Pathalias reads the UUCP Map Project maps (they need to be extracted
    from the postings first) and constructs a database containing the
    minimum cost route to any machine in the maps.  This database can
    then be used with any mailer that knows how to search the database
    (eg: smail 2.5, Zmailer?, and some versions of sendmail.  Smail 3
    comes bundled with pathalias).

    There were previous versions of this program.  You must use
    pathalias version 10 (latest version), because some map format
    changes have been made and only pathalias 10 can parse them.
    If your pathalias doesn't give a syntax error on:
    echo "file {foo}" | pathalias
    It's the new one.

    There were other route-generating programs, but all (as far as
    I know) are very obsolete, and none run as fast as pathalias
    (still, which can be rather hard on machines with smallish virtual
    memory or RAM capacities).

    pathalias 10 is available from comp.sources.unix archives,
    volume 22.  A patch was just released in comp.sources.unix
    (vol 25) that addresses an oddity when used with smail (not that
    I've ever noticed it).

uuhosts: Author John Quarterman

    The "defacto" standard UUCP Map Project map unpacker.  Includes
    a program to arbitrarily view individual map entries.  Uuhosts
    implements trojan horse/virus security by running under
    a "chroot()" system call.  Uuhosts does not appear to be
    actively maintained, and the last versions that I have inspected
    were unable to easily compress the maps (a full set of maps
    is >6000 blocks), had no provision for automatically
    running pathalias, and will not work with the newest version
    of cnews.  Further, uuhost's header checking is so picky
    that the slightest change in the map format will cause
    uuhosts to reject map updates.

    Use of uuhosts now will require some minor hacking - and this
    hacking will stretch your knowledge of Bourne shell programming.

    The last edition, "uuhost4" (version 1.69) appears to have
    been posted in comp.sources.unix in volume 3, 1986.

    Do not be confused by Jan-Piet Mons "uuhost 2.0" program posted
    in alt.sources.  This is not a map unpacker.  It is just
    a map viewer, and is a subset of the real uuhosts.

unpackmaps: Author Chris Lewis* <[e-mail]>

    Unpackmaps is a superset of the functionality of uuhosts.
    It obtains its security by doing the map unpacking with
    a specialized parser that knows the map article format
    rather than invoking a shar/shell.  Compression and pathalias
    invocation is automatic, correctly takes into account
    the change date of local configuration files, and will
    work with the latest Cnews.

    The newest version of unpackmaps, version 4.0, is currently
    in beta test, and appeared in alt.sources and comp.mail.uucp
    July 12, 1992.  This version is entirely written in C,
    is considerably faster than unpackmaps 3 or uuhosts, has
    considerably more features, and will work with Brian Reids
    PostScript net maps too.

    The beta version nows seems stable enough for general use.
    After the beta, it will be reposted in comp.sources.misc
    or comp.sources.unix.
--
Chris Lewis; [e-mail]; Phone: Canada 613 832-0541
Psroff 3.0 info: [e-mail]
Ferret list: [e-mail]